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1.  INTRODUCTION 

This  Quarterly  Technical  Report  is  the  current  edition  in  a 
series  of  reports  which  describe  the  work  being  performed  at  BBN 
in  fulfillment  of  several  ARPA  work  statements.  This  QTR  covers 
work  on  several  ARPA-sponsored  projects  including  1)  development 
and  operation  of  the  SATNET  satellite  network;  2)  development  of 
the  Pluribus  Satellite  IMP;  3)  Remote  Site  Maintenance 
activities;  4)  internetwork  monitoring;  and  5)  development  of  the 
Mobile  Access  Terminal  Network.  This  work  is  supported  under 
contracts  MDA903-76-C-0252,  N00039-78-C-0405,  MDA903-80-C-0353, 
and  N00039-79-C-0386  and  is  described  in  this  single  Quarterly 
Technical  Report  with  the  permission  of  the  Defense  Advanced 
Research  Projects  Agency.  Some  of  this  work  is  a  continuation  of 
efforts  previously  reported  on  under  contracts  DAHC15-69-C-0179t 
F08606-73-C-0027,  F08606-75-C-0032,  and  MDA903-76-C-021 3. 
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2.  SATNET  DEVELOPMENT  AND  OPERATION 
2.1  T&M  Problem 

Problems  with  the  the  transfer  of  T&M  data  to  the  Satellite 
IMP  have  occupied  a  large  share  of  our  time  during  the  last 
quarter.  The  current  situation  with  this  function  at  the 
individual  SATNET  sites  is:  the  Tanum  site  has  yet  to  receive  a 
PSP  terminal,  without  which  no  T&M  data  is  generated;  the 
Goonhilly  Satellite  IMP  has  never  been  successful  in  commanding 
the  CMM  of  its  PSP  terminal  in  order  to  enable  the  transfer  of 
T&M  data  from  the  PSP  terminal  to  the  Satellite  IMP  (CMM  commands 
from  the  Satellite  IMP  fail  to  echo,  which  indicates  that  the 
commands  are  ignored);  the  Clarksburg  site  has  not  been  a 
participating  member  of  SATNET  since  the  beginning  of  December 
due  to  transmitter  refurbishing;  and  the  Etam  site  appears  to 
have  a  fundamental  problem  with  the  transfer  of  T&M  data  to  the 
Satellite  IMP. 

The  T&M  problem  manifested  at  Etam  is  that  the  site  fails  to 
receive  about  10)  of  its  own  Hello  packets,  due  primarily  to 
hardware  checksum  errors  when  T&M  is  enabled  and  when  other 
stations  are  on  the  regular  SATNET  channel.  Concurrently,  Etam 
receives  all  of  Goonhilly's  and  Tanum's  Hello  packets  correctly, 
and  Goonhilly  and  Tanum  receive  all  Hello  packets  from  all  three 
sites  correctly. 
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To  determine  where  packets  with  incorrect  checksums  have 
been  altered,  we  patched  the  Satellite  IMP  to  crash  upon  receipt 
of  one  of  these  damaged  packets.  Once  the  Satellite  IMP 
crashed,  we  searched  memory  buffers  to  examine  the  packet  in 
detail.  The  results  of  these  searches  are  given  below. 

-  In  almost  all  cases  of  packets  received  with  hardware 
checksum  errors  but  good  header  checksums,  the  packets  were 
verified  to  be  short;  i.e.,  fewer  words  than  indicated  by 
the  packet  length  in  the  header  were  transferred  into  memory 
by  the  DMA.  (We  trust  the  packet  length  in  the  header 
because  the  header  checksum  is  valid.) 

-  In  several  cases,  Hello  packets  were  received  with  the  last 
two  T&M  words  missing,  with  an  incorrect  hardware  checksum, 
and  with  a  correct  header  checksum.  The  packet  failed  the 
Satellite  IMP  hardware  checksum  test  because  the  hardware 
checksum  indicator  is  carried  in  the  missing  4th  T&M  word. 

-  In  one  case,  a  stream  packet  from  Goonhilly  destined  for 
Tanum  (part  of  the  ARPANET  direct  connection  via  SATNET, 
line  78)  was  received  with  four  words  missing,  with  an 
incorrect  hardware  checksum,  and  with  a  correct  header 
checksum.  Since  we  could  not  determine  what  the  original 
data  were  supposed  to  be,  we  could  not  assert  that  T&M  data 
only  were  missing  and  not  packet  information. 
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All  considered,  we  were  unable  to  find  a  revealing  pattern  of 
failure  among  these  damaged  packets. 

Further  tests  have  shown  that  the  problem  disappears  at  the 
Etam  and  Clarksburg  sites  when  they  are  crosspatched  at  their 
modem  outputs  while  T&M  data  are  appended  to  the  packets.  Also, 
the  problem  disappears  when  Etam  is  transmitting  by  itself  on  the 
test  channel.  Correctness  of  the  T&M  data  in  these  situations 
has  yet  to  be  determined  by  Comsat.  In  the  tests  at  Clarksburg, 
the  Satellite  IMP  was  temporarily  connected  to  the  Tanum  PSP 
terminal,  so  as  to  provide  access  to  T&M  data.  Subsequently,  the 
PSP  terminal  was  shipped  to  Tanum  and  is  no  longer  available  for 
testing.  Since  the  UET  terminal  as  of  this  time  is  incapable  of 
generating  T&M  data,  the  Clarksburg  site  can  provide  no  more 
insight  into  the  problem. 

While  conducting  the  above  tests,  we  were  made  aware  that 
the  PSP  terminal  design  was  never  supposed  to  provide  T&M  data 
when  in  any  crosspatch  mode  which  excludes  the  modem.  What  this 
means  operationally  is  that  any  time  the  PSP  terminal  is  placed 
into  data  crosspatch  mode,  the  Satellite  IMP  must  first  issue  the 
disable  T&M  data  transfer  command  to  the  CMM  to  prevent  the 
Satellite  IMP  from  attempting  to  process  absent  data. 

Since  a  loss  of  as  many  as  four  words  in  the  packet  has  been 
seen,  we  performed  experiments  equivalent  to  increasing  the  guard 
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times  to  verify  whether  the  problem  is  resulting  from 
insufficient  time  to  transfer  the  data  to  the  Satellite  IMP.  For 
reference,  last  year  at  this  time  the  guard  time  was  260 
microseconds.  When  the  Satellite  IMP  was  plagued  by  the  extra 
SYN  problem  last  fall,  we  increased  the  guard  by  another  260 
microseconds  to  accommodate  the  increased  number  of  bits. 
Subsequently,  the  extra  SYN  was  eliminated  through  a  hardware 
modification  of  the  Honeywell  316  modem  interface  cards.  Later, 
when  the  PSP  terminal  was  installed,  the  preamble  was  reduced  by 
Comsat  from  60/60  (carrier  sync/bit  sync)  channel  symbols  to 
32/64  channel  symbols,  a  reduction  of  750  microseconds.  Since 
the  preamble  was  expected  to  change  again  with  the  introduction 
of  PSP  terminals  in  all  sites,  the  interpacket  gaps  specified  by 
the  Satellite  IMP  program  were  not  altered  to  reflect  the  new 
situations;  hence,  interpacket  guard  times  increased  by  that 
amount  to  a  current  total  of  1.27  milliseconds.  This  figure 
seems  more  than  ample,  but  to  settle  the  question  of  whether  the 
guard  time  is  sufficient,  we  made  the  following  tests. 

First,  T&M  was  enabled  at  Etam,  which  began  losing  10%  of 
its  own  Hello  packets  due  to  hardware  checksum  errors.  Next, 
Goonhilly  was  placed  into  its  loader/dumper  program.  Since  the 
transmission  order  of  Hello  packets  is  Etam,  followed  by 
Goonhilly,  followed  by  Tanum,  followed  by  Clarksburg,  the  net 
effect  is  to  place  a  10  millisecond  gap  between  Etam's  Hello 
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packet  and  Tanum's  Hello  packet,  equivalent  to  increasing  the 
guard  band  between  the  two  by  10  milliseconds.  The  results  were 
identical  to  those  above;  Etam  continued  to  lose  10%  of  its  Hello 
packets  due  to  hardware  checksum  errors,  no  matter  whether  Etam's 
Hello  packet  was  first,  second,  third,  or  fourth.  With  these 
results,  we  concluded  that  the  interpacket  guard  times  were  not 
the  cause  of  the  problem. 

2.2  Software  Problems  Fixed 

We  found  a  bug  in  the  synchronization  code  which  was  able  to 
prevent  the  Satellite  IMP  from  achieving  reservation 
synchronization  during  particular  traffic  patterns  on  the 
satellite  channel.  The  cause  of  the  problem  was  due  to  the  dummy 
scheduling  algorithm  ignoring  all  reservations  arriving  in  the 
remainder  of  the  PODA  information  subframe  after  the  central 
scheduling  queue  QC  emptied.  The  reason  the  bug  did  not  surface 
earlier  is  that  in  normal  field  operations,  the  traffic  is  low 
enough  that  no  reservations  will  arrive  after  QC  empties  and 
before  the  control  subframe  begins.  Similarly,  in  normal  test 
operations,  the  channel  is  either  overloaded,  in  which  case  QC 
never  empties,  or  underloaded,  in  which  case  no  reservations  will 
arrive  after  QC  empties  and  before  the  control  subframe  begins. 

The  fix  to  the  bug  requires  that  when  QC  is  empty,  the  dummy 
scheduling  algorithm  moves  into  QC  from  the  reservation  queue  QR 
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those  entries  which  have  been  received  before  the  control 
subframe  begins.  Dummy  scheduling  then  proceeds  as  before  on  a 
nonempty  QC.  To  ensure  adequate  scheduling  time  among  all  sites, 
the  first  entry  on  QC  is  scheduled  for  the  reservation  received 
time  plus  one  virtual  slot  as  its  dummy  scheduling  time. 

2.3  Hardware  Problems  Fixed 

During  the  last  quarter  several  hardware  problems  appeared, 
which  we  diagnosed  and,  when  related  to  the  Honeywell  316,  fixed. 
A  miswiring  on  the  Clarksburg  Honeywell  316  modem  interface 
boards  interfered  with  the  data  transfer  between  the  Satellite 
IMP  and  the  UET  terminal.  A  memory  failure  problem  at  the 
Clarksburg  Satellite  IMP  and  a  terrestrial  line  noise  problem  at 
the  Etam  Satellite  IMP  were  traced  to  Honeywell  316  power  supply 
voltages  which  had  drifted  outside  of  nominal  range. 

We  participated  in  the  discovery  of  several  problems  with 
the  power  supply  on  the  PSP  terminal  at  Etam;  Comsat  traced  the 
first  to  a  defective  voltage  regulator  and  the  second  to  failed 
capacitors . 

When  a  failure  occurred  in  the  circuit  between  the  Comsat 
gateway  and  the  Clarksburg  Satellite  IMP,  it  was  originally 
thought  that  the  ACC  VDH  interface  module  had  failed  as  it  had 
previously  this  year,  since  both  the  Honeywell  316  and  the  PDP-11 
diagnostics  were  successfully  run.  Diagnostics  on  the  ACC 
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hardware  were  not  available  at  the  time.  The  failure  was  finally 
traced  to  a  defective  power  supply  in  the  modem  eliminator 
between  the  Satellite  IMP  and  the  gateway.  The  modem  eliminator 
was  replaced  and  the  problem  disappeared.  We  have  since  arranged 
to  have  ACC  hardware-diagnostics  software  available  at  Comsat  for 
immediate  use  to  check  the  VDH  hardware. 
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3.  PLURIBUS  SATELLITE  IMP  DEVELOPMENT 

During  the  last  quarter,  the  Host-Access  Protocol  definition 
was  further  solidifiec .  Section  3-1  summarizes  its  current 
state.  Section  3-2  describes  a  stand-alone  TENEX/T0PS-20  program 
which  produces  a  graphical  representation  of  satellite  channel 
activity  from  data  reported  to  EXPAK.  Below  are  summarized  the 
progress  with  the  implementation  of  the  Host-Access  Protocol,  the 
implementation  of  a  terrestrial  landline  loader/dumper,  and  the 
satellite  modem  interface  boards.  In  addition,  a  significant 
milestone  was  passed  with  the  first  Pluribus  Satellite  IMP  (PSAT) 
prepared  and  shipped  from  BBN  and  installed  at  Lincoln 
Laboratory. 

Major  accomplishments  during  the  last  quarter  concerning  the 
Host  Access  Protocol  Module  are  the  implementation  of  the  the 
link  restart  procedure  and  the  acceptance/refusal  (A/R) 
mechanism,  both  of  which  are  described  in  W-Note  4.  As 
described,  link  restarts  are  performed  upon  the  receipt  of  a 
restart  message;  afterwards,  a  message  is  sent  out  to  indicate 
restart  completion.  When  done,  the  circuit  statistics  between 
the  two  sides  are  synchronized. 

At  present  the  A/R  decision  is  strictly  local;  network  wide 
decisions  will  be  designed  later,  when  more  experience  is  gained 
with  network  operation.  Testing  of  the  A/R  mechanism  was  done  by 
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connecting  two  PSATs  via  a  local  host  connection  and  using 
internal  message  generators  to  generate  traffic  at  high  rates. 
Because  of  the  symmetry  of  the  Host-Access  Protocol,  each  PSAT 
looks  like  a  real  host  to  the  other  PSAT;  hence,  traffic  can  be 
sent  in  either  direction  by  enabling  the  message  generator  in  the 
appropriate  PSAT. 

To  guard  against  the  situation  where  buffers  are  unavailable 
for  host  traffic,  we  implemented  a  mechanism  which  checks  the 
queue  size  during  enqueuing  and  limits  the  queue  to  a  maximum 
size.  In  particular,  we  modified  the  Enqueue  and  the  Dequeue 
procedures  so  that  procedures  which  manipulate  queues  with 
Enqueue  and  Dequeue  can  now  limit  the  maximum  queue  size.  This 
feature  provides  rudimentary  resource  level  flow  control  to  take 
effect  whenever  the  PSAT  accepts  traffic  faster  than  it  can  send. 
Since  the  transmit  and  receive  sides  of  the  local  host  hardware 
interface  may  run  at  slightly  different  rates,  queue  limitation 
is  necessary  when  running  loopback  tests  between  two  PSATs  to 
prevent  memory  buffers  from  being  over-allocated. 

The  terrestrial  line  loader/dumper,  a  stand-alone  Pluribus 
program  which  provides  the  user  the  capability  to  load,  dump, 
verify,  and  debug  PSATs  remotely,  was  finished.  The  program  is 
currently  being  used  by  the  PSAT  programmers  for  access  to  PSATs 
via  the  ARPANET. 
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Implementation  required  building  an  interface  to  packet  core 
routines  in  the  Pluribus  operating  system  (Stage),  building  a 
device  discovery  module,  and  modifying  packet  core  so  that  it 
recognizes  Internet  Protocol.  The  standard  ARPANET  utility  (U) 
program  was  also  modified  to  be  able  to  handle  Internet  Protocol 
with  Pluribus  machines. 

A  large  amount  of  time  was  spent  modifying  and  debugging  the 
boards  of  the  Satellite  Modem  Interface  (SMI)  so  that  it  will  be 
able  to  send  multi-packet  bursts  at  3  Mb/s.  The  results  of  our 
latest  tests  indicate  that  the  modifications  were  successful  and 
that  the  SMI  hardware  is  indeed  capable  of  operating  at  3  Mb/s. 
(Note,  however,  it  has  yet  to  be  verified  whether  the  PSAT  has 
enough  computational  bandwidth  to  operate  at  3  Mb/s.) 

The  SMI  contains  three  special  purpose  boards  and  one 
standard  DMA  board.  The  three  special  purpose  boards,  designated 
as  a  transmit  board,  a  receive  board,  and  a  timing  board,  were 
the  ones  that  were  modified.  In  particular,  the  transmit  board 
was  rewired  to  handle  multi-packet  bursts  at  the  high  rate.  The 
receive  board  was  rewired  to  increase  the  packet  length  field 
from  8  bits  to  12  bits.  On  the  receive  board,  the  PROMs,  which 
define  the  finite  state  machine  for  the  line  protocol,  were 
changed  to  enable  high  rate  operation.  The  timing  board  was  also 
changed  as  a  consequence  of  changes  made  to  the  transmit  board; 
namely,  control  bits  on  each  were  redefined  for  multi-packet 
operation . 
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3.1  Host-Access  Protocol  Definition 


The  following  subsections  summarize  the  Host-Access  Protocol 
(HAP)  definition  as  of  April  25,  1980.  It  is  based  upon  W-Note  4 
and  subsequent  meetings  held  on  January  27  and  March  24,  1980. 
Details  and  formats  will  be  provided  at  a  later  time. 


3.1.1  Message  Level 


Error  Control 


Satellite  Channel: 

-  Choice  of  several  reliability  levels  will  be  provided. 

-  "Data  error  delivery”  bit  (host  to  PSAT)  defined. 

-  "Data  errors  detected”  bit  (PSAT  to  host)  defined. 

Host  -  PSAT  Link: 

-  All  HAP  message  headers  and  control  messages  (level-3) 
have  software  checksum  (discard  if  bad,  no 
retransmission) . 

-  No  link  error  control  on  data  to  be  implemented  in 
initial  system  since  remote  connections  may  use  HDLC  or 
equivalent  at  level-2. 

Flow  Control 


-  Selective  acceptance/refusals  (non-blocking)  defined. 

-  A/R’s  (acceptance/refusals)  may  be  turned  off  for  "pure 
discard”  interface. 

-  UR*s  (unnumbered  refusals)  are  returned  for  certain 
conditions  in  "pure  discard”  interface. 

-  Acceptable  priorities  ("GOPRI”)  are  passed  periodically. 

-  Additional  rate-oriented  flow  control  information  may  be 
added  later  after  internal  network  flow  control  is 
well-defined . 
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Link  Monitoring 

-  Host  and  PSAT  will  exchange  counts  of  messages  sent  and 
received,  number  of  errors,  etc.,  in  periodic  status 
messages  (about  once  per  second). 

-  Counts  are  exchanged  in  a  manner  which  allows  either  side  to 
determine  error  and  discard  statistics  for  both  directions. 

Multilinking 

-  The  use  of  two  or  more  physical  links  to  increase  host-PSAT 
bandwidth  and/or  reliability  will  be  done  at  the 
level-3/level-4  interface  (i.e.,  each  link  will  have 
separate  flow  control  exchanges,  monitoring,  and  restarts). 

Port  Expansion 


-  Port  expansion  will  be  provided  by  a  level-2  header 
containing  local  addressing  information  in  chip-compatible 
format . 

-  Port  expansion  will  be  handled  as  ’local  port  configuration' 
by  PSAT  as  required,  allowing  other  level-2  formats  (e.g., 
HDLC)  when  needed. 

Max  Message  Size 

-  Maximum  message  size  will  be  16,384  data  bits  (2**14)  plus 
up  to  400  bits  of  control  information  at  level-3  and  above. 

Time  to  Live 


-  Four  choices  of  time  to  live  (aka  'holding  time')  will  be 
provided  with  values  to  be  determined;  a  different  set  of 
values  may  be  used  for  stream  messages. 

Inter-Arrival  Time  Control 

-  A  pause  mechanism  will  be  used  to  introduce  a  constant 
elapsed  time  following  the  end  of  each  output  transfer 
before  a  new  transfer  can  begin;  pause  value  is  to  be  tuned 
manually  (initially)  for  each  end  of  link. 
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3.1.2  Setup  Protocol 


-  Setup  protocol  operates  on  top  of  message  level  (i.e.,  a 
level-4  protocol);  all  setup  messages  have  software 
checksums. 

-  Hosts  send  request  messages  (i.e.,  create,  delete,  join, 
leave,  change)  to  the  service  host  (address  "zero")  in  the 
local  PSAT. 

-  The  PSAT  returns  a  reply  message  in  response  to  a  request 
message;  if  a  reply  is  not  immediate,  the  PSAT  also  sends  an 
ack  message. 

-  The  host  returns  an  ack  in  response  to  a  correctly  received 
reply. 

-  The  PSAT  also  sends  a  notification  message  to  the  host  for 
certain  events  (e.g.,  'stream  deleted');  the  host  returns  an 
ack. 

-  Internet  setups  are  supported  as  in  SATNET  (i.e.,  internet 
headers  are  used  in  request/reply  messages,  and  no  internet 
notifications  are  sent) . 


3.1.3  Streams 


-  Hosts  deal  with  'host  streams',  whereas  PSATs  may  combine 
two  or  more  host  streams  originating  at  the  same  site  for 
channel  scheduling  purposes  ('channel  streams'). 

-  Initially,  only  simplex  host  streams  (one  source  host  per 
stream)  will  be  supported;  'shared  streams'  (two  or  more 
source  hosts  and  host-level  coordination)  may  be  supported 
at  a  later  date  if  required. 

-  A  choice  of  several  ' powers-of-two'  stream  interval  sizes 

will  be  provided;  initially  the  choices  will  be  1,  2,  4,  or 
8  PODA  frames  (where  a  PODA  frame  will  be  either 

approximately  20ms  or  40ms,  to  be  determined). 

-  Messages  sent  in  a  particular  host  stream  may  be  addressed 
to  any  destination  (including  groups);  also,  more  than  one 
message  may  be  passed  to  the  PSAT  for  transmission  in  the 
same  stream  slot;  i.e.,  the  PSAT  will  concatenate  distinct 
messages.  (Note:  this  is  a  change  from  the  'single 
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address/no  concatenation  per  host  stream*  solution  proposed 
in  W-4,  and  has  been  made  to  allow  more  effective  traffic 
multiplexing  by  hosts  in  each  host  stream.) 

-  Stream  priority  (P),  interval  (I),  reliability  (R),  and  slot 
size  are  defined  by  the  host  in  the  stream  setup  message. 
Each  distinct  set  of  values  of  the  first  three  of  these 
parameters  (P,I,R)  defines  a  unique  host  stream.  A  unique 
7-bit  stream  identifier  will  be  assigned  by  the  PSAT  at 
setup  time,  and  must  be  sent  by  the  host  in  the 
Type-of-Service  (TOS)  field  of  each  data  message  sent  in  the 
stream.  (Note:  the  7-bit  identifier  is  a  change  from  what 
was  described  at  the  March  Wideband  meeting.) 

-  The  specification  of  stream  slot  size  must  take  into  account 
the  number  of  distinct  messages  the  host  expects  to  send  in 
a  single  stream  slot,  as  well  as  the  maximum  message  size 
and  'reliability  length'  for  the  control  portion  of 
messages.  Details  of  this  specification  are  to  be 
determined . 

-  The  stream  slot  size  must  also  take  into  account  whether  a 
stream  destination  is  attached  to  a  PSAT  operating  at  a 
reduced  channel  receiving  rate  (a  low-rate  site,  or  LRS) . 
This  will,  in  general,  involve  resource  negotiation 
mechanisms  which  are  still  to  be  worked  out.  The  presently 
defined  approach  calls  for  the  requesting  host  to  optionally 
supply  a  list  of  destination  addresses  to  the  PSAT,  allowing 
the  latter  to  identify  any  associated  with  an  LRS.  (The 
initial  implementation  will  assume  that  all  sites  receive  at 
the  same  rate.) 

-  A  rapid-change  stream  slot  size  capability  may  be  added  at  a 
later  date,  pending  further  study  (at  present,  slot  size  may 
be  changed,  along  with  any  other  stream  parameter,  only  by 
use  of  the  setup  mechanism). 


3.1.4  Group  Addressing 


-  A  group  address  is  established  by  a  setup  request  from  a 
host,  which  automatically  becomes  a  member  of  the  group; 
additional  members  must  be  established  by  use  of  the 
distributed  join/leave  mechanism  following  distribution  of 
the  group  address  by  the  host  to  the  other  desired  members 
(i.e.,  top-down  binding). 
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-  To  prevent  membership  confusions  from  arising  following  a 
host  or  PSAT  crash  recovery,  the  PSATs  also  assign  a  48-bit 
key  along  with  the  group  address.  The  key  must  be 
distributed  along  with  the  address  to  all  hosts  which  are  to 
become  members,  and  is  supplied  by  the  hosts  in  join/leave 
and  delete  messages. 

-  A  group  address  can  be  deleted  by  a  delete  request  from  any 

member  host.  In  addition,  a  group  address  will 

automatically  be  deleted  by  the  PSATs  if  it  is  not  used  for 
an  elapsed  (to  be  defined)  time  (this  time  will  probably  by 
long  compared  to  stream  lifetimes,  e.g.,  hours  or  days, 
depending  on  the  availability  of  unassigned  address  space). 


3-1.5  Notifications 


-  PSATs  will  send  notification  messages  to  appropriate  hosts 
whenever  a  group  address  of  which  they  are  a  member  is 
deleted,  or  whenever  one  of  the  hosts'  streams  is  suspended, 
resumed,  or  deleted  due  to  resource  availability  changes. 

3.2  SCOPE 

SCOPE  is  a  TENEX/TOPS-20  program  to  produce  graphical 
representations  of  satellite  channel  activity  from  data  reported 
to  EXPAK.  Program  operation,  which  is  modelled  after  that  of  an 
oscilloscope,  allows  users  to  specify  time  delays,  trigger 
events,  trace  length,  and  resolution.  The  information  is 
displayed  as  one  to  five  lines  of  "trace",  with  status  lines  to 
indicate  collection  site,  frame  number,  and  the  value  of 
user-settable  parameters. 

SCOPE  is  significantly  more  powerful  and  flexible  than 
EXPAK's  Channel  Trace  facility  developed  for  SATNET.  Although 
intended  for  use  with  all  of  the  satellite  networks  (PSAT, 
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SATNET,  and  MATNET),  its  actual  use  with  the  latter  two  awaits 
changes  in  the  SATNET  Satellite  IMP  program. 

SCOPE,  while  currently  terminal  independent,  is  designed  as 
if  the  user's  terminal  were  a  CRT  terminal.  The  TENEX/T0PS-20 
terminal  mode  should  be  set  to  type  0  (printing  TTY),  and  the 

LENGTH  and  WIDTH  commands  should  be  set  to  the  screen  width  and 
page  length  (typically  24  X  80  for  CRT  terminals).  If  a 
hard-copy  terminal  is  used,  INDICATE  mode  should  be  set.  SCOPE 
will  read  the  page  length  and  width  when  it  starts  up  and  will 
keep  trace  lines  small  enough  to  fit.  Until  we  change  to  the 
Rutgers  supplied  PASCAL  compiler  recently  installed  at  BBN,  the 
symbol  will  be  used  instead  of  the  symbol  "i"  for  a  packet 
delimiter,  and  lower  case  letters  will  be  converted  to  upper  case 
letters  on  output.  On  input,  the  program  has  been  written  to 
accept  either  case. 

There  are  three  principal  things  printed  out  by  the  program: 
Status  Line  1  (at  the  top  of  the  screen),  Status  Line  2  (at  the 
beginning  of  each  frame),  and  the  channel  trace  itself  (which  may 
be  up  to  five  lines  long).  Each  is  described,  along  with  sample 
printouts,  in  detail  in  the  next  sections. 
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3.2.1  Status  Line  1  Display 

Delayl  Triggers  Delay2,  Window  Resolution  Filters 
210  uS  <0FF>  -40  uS,  21.9  ms  (  171  bits/char)  <FILTERED> 

Delayl.  This  represents  the  length  of  time  that  must  pass 
from  the  beginning  of  the  frame  before  the  trace  can  begin. 
Channel  trace  data  representing  bursts  that  BEGIN  before  this 
delay  time  will  be  skipped  over. 

Triggers.  This  will  be  one  of  <0ff>  <Any>  or  <Triggered>. 
If  triggering  is  disabled,  <0ff>  will  be  printed.  If  triggers 
are  enabled,  but  the  first  pattern  is  one  that  matches  all  sites 
and  all  burst  types,  then  <Any>  is  printed.  Otherwise 
<Triggered>  is  printed.  Triggering  will  not  occur  until  after 
Delay  1  has  passed.  The  trigger  is  considered  to  occur  at  the 
beginning  of  the  first  burst  whose  source  and  type  meet  the 
triggering  tests. 

Delay2.  This  number  is  the  time  forward  or  backward  from 
the  trigger  event,  or  the  end  of  Delay  1  if  no  triggering,  to  the 
beginning  of  the  trace.  In  the  example  above,  the  trace  is  to 
begin  at  210  -  40  s  170  microseconds  after  the  start  of  the 
frame.  This  delay  will  not  back  up  past  the  beginning  of  the 
frame. 
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Window  (size).  This  is  the  length  of  time  represented  by 
the  trace.  In  the  example,  the  trace  is  21.9  milliseconds  long. 

Resolution.  This  value  indicates  the  resolution  of  the 
trace  in  terms  of  bit-times  per  character  position.  For  a  trace 
length  of  21.9  milliseconds,  using  five  lines  of  trace  printout 
at  79  characters  per  line,  this  would  be  21.9  ms/(5*79)  or  55.5 
us/char.  In  the  PSAT  network,  where  there  are  3*088 
bits/microsecond,  this  becomes  171  bits  per  character  position. 

Filters.  This  will  be  either  <ALL>  if  the  first  filter 
passes  all  sites  and  all  burst  types,  or  <Filtered>  otherwise. 

3.2.2  Status  Line  2  Display 

Net  Site  Time/div  Frame  Interval  Parameter 

PSAT:  ISI  500  uS/+  Frame  //E0  +214  uS  >>Delay  1 

Net.  Either  SATNET  or  PSAT. 

Site.  Name  of  site  sending  trace  information. 

Time/division.  The  "time-line”  part  of  a  trace  printout  has 

periodic  division  markers,  like  "--+ - + — ".  The  time  per 

division  is  the  time  between  successive  plus  signs. 

Frame.  This  is  the  frame  number  as  reported  by  the 
collecting  site.  This  number,  from  0  to  255,  is  printed  in 
hexadecimal  for  the  PSAT  network  and  in  octal  for  the  SATNET 


network. 
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Interval,  or  trigger  delay.  This  item  is  displayed  only 
when  triggering  is  enabled.  Since  triggering  causes  an 
indeterminate  delay,  this  number  is  printed  to  indicate  the  time 
from  the  beginning  of  the  frame  until  the  actual  beginning  of  the 
trace  displayed. 

Parameter.  This  indicates  which  of  the  program  parameters 
is  currently  being  selected  for  changing  upon  request  from  the 
user . 

3.2.3  Trace  Line  Display 


I .  . !  I . !  DL ! 

L..!  C . !  QH! 

+ - +-S - + - + - + - + 


Top  line:  Burst  source. 

Second  line:  (and  sometimes  third  line):  Burst  type. 

Third  line:  Time  line. 

The  example  shows  four  bursts.  They  are: 

Leader  packet  (L)  from  ISI  (I); 

Centralized  Stream  (CS)  from  ISI  (I); 

Query  packet  (Q)  from  DCEC  (D); 

Hello  packet  (H)  from  Lincoln  (L). 

Information  in  status  lines  1  and  2  would  indicate  the  time 
per  division  and  the  time  per  character  position.  In  terms  of 
characters,  the  example  packet  lengths  are  4,  12,  1,  and  2. 

If  the  resolution  chosen  is  large  enough,  more  than  one 
packet  may  fall  at  the  same  character  position.  If  this  occurs, 
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the  program  will  attempt  to  make  small  adjustments  to  the 
printout  to  retain  as  much  information  as  possible  in  the 
display.  If  an  adjustment  cannot  be  made,  then  the  symbol 
will  be  printed  on  the  top  line  to  indicate  more  than  one  packet 
at  that  character  position. 
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4.  REMOTE  SITE  MAINTENANCE 

4.1  Remote  Operations 

BBN  received  permission  to  operate  on  the  Advanced  Command 
and  Control  Architectural  Testbed  (ACCAT)  classified  sub-net  in 
late  January  1980.  The  first  contact  was  made  over  the  network 
on  February  15,  1980.  Since  that  time,  arrangements  have  been 

made  to  have  regular  contacts  with  the  Remote  Site  Module  (RSM) 
at  the  Naval  Ocean  Systems  Center  (NOSC).  These  contacts  are  now 
made  on  Friday  of  those  weeks  in  which  NOSC  operates  on  Friday, 
and  Thursday  of  the  other  weeks.  This  arrangement  has  allowed 
BBN  to  transfer  dumps  from  NOSC  to  Cambridge,  along  with  certain 
other  information  which  is  needed  for  the  analysis  of  the  dumps. 

4.2  Multiple  File  Transfers 

The  installation  of  new  or  revised  commands,  or  of  the 
operating  system,  usually  requires  the  transfer  of  more  than  a 
single  file.  The  ordinary  implementation  of  the  File  Transfer 
Protocol  (FTP)  is  single  file  oriented.  During  the  past  six 
months,  BBN  has  been  developing  extensions  of  this  protocol  which 
can  be  effectively  used  for  transferring  a  number  of  files.  An 
experimental  implementation  of  this  augmented  FTP  is  now  in 
operation  on  BBN-UNIX  and  at  the  other  RSMs .  An  RFC  for  these 
additions  is  in  preparation,  and  will  be  submitted  during  the 
next  quarter. 
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Initially,  a  version  of  FTP  was  prepared  which  simply  stored 
a  group  of  files  which  were  specified  using  the  UNIX  wild-card 
conventions.  These  files  would  then  be  stored  at  a  single 

directory  level  in  the  remote  host.  Since  it  is  as  easy  to 

manipulate  a  directory  as  an  ordinary  file  in  the  UNIX  system,  it 

seemed  desirable  to  expand  the  FTP  servers  to  include  commands 
which  deal  with  the  creation  of  directories.  Furthermore,  since 
other  hosts  on  the  ARPANET  have  operating  systems  which  support 
tree-structured  directories,  the  commands  for  manipulating 
directories  should  be  defined  with  these  systems  in  mind, 

particularly  TOPS20  and  MULTICS. 

The  proposed  additions  are  as  follows. 

XMKD  child 

Make  a  directory  with  the  name  "child". 

XRMD  child 

Remove  the  directory  with  the  name  "child". 

XCUP 

Change  to  the  parent  of  the  current  working  directory. 

The  directory  which  is  created  or  removed  is  a  subdirectory  of 
the  current  working  directory,  unless  the  string  contains 
sufficient  information  to  specify  otherwise  to  the  server,  for 
example,  an  absolute  pathname  in  the  UNIX  remote  host. 
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The  XCUP  command  is  a  special  case  of  CWD.  It  is 
particularly  useful  when  one  is  transferring  directory  trees 
between  hosts  using  different  operating  systems.  It  frees  the 
store/retrieve  programs  from  a  need  to  understand  the  details  of 
the  file  naming  syntax  on  the  remote  host. 

4.3  Graphics  System  Library  and  Documentation 

Only  limited  documentation  has  been  available  for  the 
graphics  subsystem  of  the  Remote  Site  Module.  In  addition,  the 
relatively  large  number  of  subroutines  which  have  been  available 
for  this  subsystem  have  not  previously  been  organized  as  a  UNIX 
archive.  As  a  result,  the  development  of  consistent  new  software 
at  BBN  and  elsewhere  has  been  impeded.  During  the  past  quarter, 
new  or  improved  documents  have  been  prepared  on  the  following 
commands . 

The  Genisco  micro-code  assembler,  gasm3,  which  assembles  the 
given  files,  puts  a  listing  on  the  standard  output  and  the 
object  code  in  the  file  g.out. 

Gld3  loads  a  program  which  has  been  previously  assembled  by 
gasm3  into  the  Genisco  PGP  (Programmable  Graphics 
Processor) . 

Pgp3  is  used  to  obtain  or  set  the  current  status  of  a 
Genisco  display  system  processor. 
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Storepic  and  restorepic  dump  the  picture  data  from  a  genisco 
bit-map  display  onto  a  disk  file,  or  restore  it  from  the 
disk  file  to  the  display  memory. 

In  addition,  documentation  of  the  hardware  at  a  level 
appropriate  for  users  and  programmers  has  been  prepared.  This  is 
supplemented  by  a  complete  description  of  the  available  device 
drivers  for  the  Genisco,  and  the  procedures  for  configuring  these 
drivers  for  a  particular  application. 

The  main  graphics  library  assembled  for  the  Genisco  includes 
the  following  elements. 

Initialization  routines: 

usefile  -  initialize  output  stream 

loadvlt  -  load  video  color  table  location  with  R,G,B  value 
ntdsfile  -  open  an  NTDS  character  definition  file 

Environment  routines: 

plselect  -  select  active  graphic  memory  planes 
colset  -  set  the  current  color 

fillit  -  select  planes  for  fill  mode  and  VLT  gating 
t  set  -  low  level  memory  plane  environment  routine 
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Drawing  routines: 


absmove 

absvec 

relmove 

relvec 

text 

ntdsym 

plset 

t_dabs 

t_drel 

t_putve 

t  vterm 


-  move  the  cursor  position  to  an  absolute  location 

-  draw  a  vector  to  an  absolute  location 

-  move  the  cursor  position  to  a  relative  location 

-  draw  a  vector  to  a  relative  location 

-  draw  a  text  string 

-  draw  a  character  from  the  NTDS  file 

-  write  this  color  into  every  screen  pixel 

-  low  level  absolute  coordinate  routine 

-  low  level  relative  coordinate  routine 

-  low  level  vector  drawing  routine 

-  low  level  vector  termination  routine 


I/O  routines: 


send  -  flush  output  stream 

gclose  -  terminate  output  stream 
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5.  INTERNET  DEVELOPMENT 

During  the  last  quarter,  we  made  substantial  additions  to 
the  CMCC  program;  these  are  detailed  in  section  5.1.  Section  5.2 
describes  the  equipment  for  two  facsimile  systems,  which  we  have 
ordered,  and  which  have  mostly  arrived  at  BBN.  Below  is 
summarized  the  current  status  on  the  VAN  gateway  and  the  LSI-11 
SATNET  gateways. 

The  1.2  Kb/s  dial-up  modem  has  been  installed  at  BBN.  We 
currently  are  writing  software  for  testing  the  bisync  and  HDLC 
connection  to  the  TELENET  test-TIP  at  Vienna,  Virginia. 

We  checked  the  bus  converter  operation  with  the  LSI-11 
gateway  and  the  PDP-11  ACC  VDH  interface  by  operating  the  VDH 
interface  diagnostic  software  in  the  LSI-11.  Subsequently, 
gateway  software  ran  successfully  in  the  LSI-11  for  a  brief  test. 

5.1  CMCC  Development 

The  CMCC  program  was  modified  to  use  internet  queue  JSYSs 
and  to  recognize  the  T0PS-20  end-of-line  character,  so  as  to 
permit  operation  on  TOPS-20  hosts.  The  program  has  been 
installed  in  the  directory  CMCC  at  ISIE  and  is  currently 
available  for  usage  by  the  entire  catenet  community. 

During  the  last  quarter,  we  added  the  following  new  features 
to  the  CMCC  program: 
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-  program  auto-start  operation, 

-  gateway  report-restart, 

-  report  filtering, 

-  gateway  polling, 

-  new  display  command  format, 

-  new  report  formats, 

-  last-time  heard  response. 

These  features  provide  the  following  functions. 

The  display  process  was  modified  to  permit  auto-start 
operation;  namely,  when  the  process  is  started  up  detached,  it 
will  automatically  begin  logging  data  for  a  permanent  record  of 
catenet  operation.  Currently  we  are  logging  traps,  gateway 
traffic  reports,  and  gateway  routing  reports. 

The  gateway  report-restart  mechanism  allows  gateways  that 
have  crashed  and  restarted  to  continue  reporting  in  the  same 
fashion  as  before  the  crash.  The  gateway  is  not  expected  to 
remember  the  reporting  parameters,  so  this  role  is  performed  in 
the  CMCC . 

Report  filtering  is  the  mechanism  whereby  the  CMCC  terminal 
process  outputs  only  that  fraction  of  the  number  of  reports 
coming  in  which  corresponds  to  the  user  specified  output 
interval.  Extra  reports  are  discarded.  This  mechanism  allows 
the  CMCC  program  to  display  and  to  log  traffic  reports  and 
routing  reports  at  longer  intervals  than  can  be  specified  in  the 
gateways  themselves.  (Because  of  a  limitation  in  the  interval 
counting  mechanism  implemented  in  the  gateways,  regular  reports 
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cannot  be  sent  any  less  frequently  than  every  65  seconds;  hence, 
the  need  for  report  filtering  to  reduce  the  number  of  reports 
being  displayed  to  the  user  or  logged.)  Originally,  the  daily 
log  was  created  by  the  gateways  being  initialized  to  send  traffic 
and  routing  reports  every  minute,  although  the  log  was  updated 
only  once  per  hour.  Currently,  the  CMCC  program  polls  gateway 
traffic  and  gateway  routing  reports  every  five  minutes,  and  the 
log  is  updated  every  half  hour.  The  recording  interval  is 
selected  so  as  not  to  overflow  the  allocated  disk  space  on  ISIE. 

With  the  gateway  polling  mechanism,  the  CMCC  program  will 
request  and  process  reports  from  identified  gateways  at  regular 
intervals.  Both  the  list  of  gateways  to  be  polled  and  the 
frequency  of  polling  are  user  specified  parameters.  Hence, 
reports  can  be  included  in  the  display  process  and  in  the  daily 
report  log  file  from  those  gateways  (such  as  RSRE,  for  example) 
which  do  not  report  automatically.  Although  data  for  the  log 
file  was  originally  collected  by  gateways  being  commanded  to  send 
reports  automatically,  with  report  filtering  to  exclude  the 
extraneous  reports,  polling  of  all  gateways  is  the  mechanism 
employed  currently.  The  reason  for  this  change  is  that  upon 
failure  of  the  host  computer  on  which  the  CMCC  program  is 
running,  automatic  gateway  reports  cannot  be  switched  to  another 
host  computer.  (Gateways  do  not  implement  authorization 
mechanisms  to  disable  automatic  reporting;  the  host  computer  that 
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has  enabled  these  reports  is  the  only  host  allowed  to  disable 
them. ) 

The  "Which  reports..."  command  format  will  now  show  how 
often  the  reports  are  being  collected,  polled,  displayed,  or 
logged,  as  appropriate. 

Formats  for  two  more  report  types,  End-to-end  statistics  and 
Queue  lengths,  were  added  to  the  gateway  reporting  formats.  With 
these  additions,  all  report  types  from  all  monitoring  gateways 
are  now  accommodated. 

As  an  added  convenience,  the  display  program  now  gives  the 
time  a  gateway  was  last  heard  if  it  is  not  being  heard.  This 
information  allows  the  user  to  search  the  log  file  at  a  specific 
time  for  diagnosing  problems.  Also,  the  log  file  is  closed  after 
every  entry,  which  allows  the  user  to  examine  the  log  file  in 
real-time . 

We  have  acquired  a  new  Pascal  compiler  from  Rutgers 
University,  which  offers  the  following  improvements  over  the  one 
previously  in  use  at  BBN. 

-  Program  execution  is  more  efficient  through  use  of  a  native 
mode  operation  which  avoids  the  T0PS-10/TENEX/T0PS-20 
compatibility  package. 

-  Easier  access  to  JSYS  calls  is  provided. 

-  The  capability  of  lower-case  strings  for  display  output  is 
provided . 
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-  Extended  file  handling  capabilities  are  provided  with 

features  that  permit  random  file  access  in  the  Pascal  code 
directly  without  resorting  to  machine  code. 

-  Multi-module  programs  can  be  debugged  without  multiple 
relinking  with  the  Pascal  debugger. 


Modifications  to  the  CMCC  program  sources  for  compatibility  with 
the  new  Pascal  compiler  have  already  been  implemented,  and  the 
new  compiler  is  currently  in  service. 


5.2  Facsimile 


Two  Rapicom  450  Computerfax  systems  and  two  DEC  LSI-11/23 
development  systems,  which  will  serve  as  part  of  the  facsimile 
systems  to  be  developed  by  BBN,  were  ordered  and  have  arrived  at 
BBN.  Yet  to  arrive  are  the  serial  synchronous  interfaces  and  the 
1822  interfaces.  The  specific  equipment  list  is  given  below: 


EQUIPMENT 


MODEL 


Rapicom  Computerfax  Transceiver 
Automatic  Document  Feeder 
DEC  LSI-1 1/23  Development  System 
Dual  Disk  Drive  UNIT 
CRT  Terminal 

Serial  Synchronous  Interface 
ACC  DMA  1822  Interface 


450 

ADF-16 
SRWXSSA-BA 
RX02 
VT100 
DUV1 1-DA 
MLH-DH/LSI 1 1 


One  Computerfax  and  one  LSI-11/23  will  be  installed  at  BBN  for 
developing  facsimile  systems.  The  other  Computerfax  will  be 
stored  temporarily  at  BBN,  while  the  other  LSI-11/23  was  shipped 
to  Dave  Mills  for  him  to  use  in  experiments.  Eventually  both 
units  will  be  delivered  to  ARPA. 
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6.  MOBILE  ACCESS  TERMINAL  NETWORK 

As  part  of  our  participation  in  the  Mobile  Access  Terminal 
Network  (MATNET)  project  during  the  last  quarter,  we  placed 
emphasis  on  the  design  and  the  fabrication  of  the  satellite 
channel  simulator.  This  work  is  described  in  section  6.1.  In 
addition,  section  6.2  describes  the  conversion  of  the  Satellite 
IMP  loader/dumper  code  for  use  in  MATNET.  Other  significant 
accomplishments  during  the  quarter  are  summarized  below. 

We  obtained  robustness  cards  from  SRI  International  for  both 
MATNET  LSI-11  processors  to  improve  the  self-test  diagnostic 
capability  of  the  gateway  and  the  Terminal  Interface  Unit  (TIU). 
These  cards  will  be  installed  into  the  gateway  and  the  TIU  before 
tests  of  these  systems  are  performed. 

The  MATNET  ACC  1822  Host-to-IMP  interface  boards  were 
installed  in  an  LSI-11  serving  as  a  TIU  for  the  Command-Control 
Network  (CCN)  project  at  BBN  to  test  the  interface  and  to 
exercise  the  TELNET  and  TCP  protocols.  During  the  test,  this 
configuration  was  interfaced  directly  to  a  host  port  on  IMP  1  of 
the  RCCnet. 

The  specialized  hardware  for  the  Red/Black  interface  of  the 
C/30  packet  switch  processor  was  designed.  This  hardware 
consists  of  a  small  printed  circuit  daughter  board  mounted  above 
the  C/30  universal  I/O  board  for  converting  between  the  TTL 
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signal  levels  internal  to  the  C/30  and  the  MIL-188C  signal  levels 
required  by  the  COMSEC  equipment.  Additional  circuitry  to 
facilitate  interface  testing,  including  an  extra  input  line  and 
an  extra  output  line,  is  also  on  the  board.  We  anticipate  that 
the  spare  output  line  will  be  used  by  the  C/30  to  generate 
trigger  pulses  for  a  logic  analyzer,  while  the  spare  input  line 
might  be  used  to  pass  timing  reference  signals  to  the  C/30. 
Manufacturing  of  this  printed  circuit  has  already  begun. 

During  the  last  quarter,  we  also  participated  in  the  MATNET 
Preliminary  Design  Review  held  at  ECI  in  St.  Petersburg,  Florida. 
In  response  to  action  items  discussed  there,  we  have  begun  a 
draft  document  of  the  MATNET  test  plan  for  phase  2B ,  and  we 
reviewed  the  timing  of  signals  being  passed  between  the  Black 
processor  and  the  Red  processor  to  verify  that  MAT  stations  are 
capable  of  filling  the  satellite  channel  under  any  arbitrary 
traffic  specification. 

6.1  Satellite  Channel  Simulator 

The  MATNET  satellite  channel  simulator  design  was  finished, 
and  fabrication  of  a  single  unit  is  almost  completed.  This 
device  reproduces  the  time  delay  resulting  from  broadcasting  to  a 
geostationary  satellite.  The  selectable  delays  are  0  to  300 
milliseconds  in  1  millisecond  steps  to  be  inserted  into  the  data 
stream,  while  the  selectable  channel  channel  bit  rates  are  9*6, 
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19.2,  51.2,  64,  and  128  Kb/s.  In  all,  four  separate  data  sources 
can  be  combined;  clocking  signals  at  the  channel  bit  rate  are 
provided  to  all  the  transmitters  and  receivers  while  data  are 
being  transferred.  A  block  diagram  of  the  simulator  is  shown  in 
Figure  6.1. 

MATNET  SATELLITE  CHANNEL  SIMULATOR 


DATA  INPUT  DATA  OUTPUT 


Figure  6.1  MATNET  Satellite  Channel  Simulator 

The  MATNET  simulator  design  is  a  derivative  of  the  satellite 
channel  simulator  for  the  wide-band  satellite  network,  where  the 
channel  rates  are  as  high  as  3  Mb/s.  In  the  MATNET  design,  where 
the  channel  rates  are  only  as  high  as  128  Kb/s,  the  internal 
systems  clock  is  reduced  by  a  factor  of  5  to  5  MHz,  and  the 
memory  is  reduced  by  a  corresponding  amount.  These  changes 
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provide  greater  margin  in  the  design  tolerances,  simplify  the 
hardware,  and  reduce  the  parts  cost. 

In  order  to  keep  the  design  of  the  simulator  simple,  several 
aspects  of  the  total  system  operation  are  not  simulated.  The 
principal  simplification  is  in  the  handling  of  the  Red  processor 
control  signals,  Packet  Type  In  (PTI),  Go  Signal  (GOSIG) ,  and 
Unique  Word  (UW).  In  the  operational  system,  the  Red  processor 
indicates  the  length  of  a  transmission  by  pulse-width-modulation 
of  the  PTI  signal.  The  actual  instant  when  a  transmission  should 
begin  is  marked  by  a  transition  on  the  GOSIG  line.  The  simulator 
ignores  the  PTI  line  and  requires  the  GOSIG  to  be  on  for  the 
entire  transmission  time.  Similarly,  the  Black  processor  will 
indicate  the  instant  when  a  transmission  is  received  by  a 
transition  on  the  UW  line,  while  the  simulator  ignores  this 
signal . 

Other  differences  between  the  simulator  and  the  operational 
system  are  related  to  the  COMSEC  and  Codec  equipment.  The 
simulator  does  not  add  fill  bits  to  the  message  and  does  not 
insert  pauses  in  the  output  stream  by  stopping  the  receive  clock. 
Thus,  it  will  not  be  possible  to  check  many  aspects  of  the  Red 
processor  I/O  code  via  the  simulator.  The  intent,  however,  is 
to  permit  multiple  Red  processor  testing  to  ensure  that  global 
synchronization  of  sites  works  properly. 
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For  versatility  and  for  providing  a  means  of  testing  the 
simulator  with  proven  Satellite  IMP  hardware,  the  unit  is  capable 
of  serving  as  a  satellite  channel  simulator  for  Satellite  IMPS  of 
both  SATNET  and  MATNET.  The  unit  has  12-pin  Burndy  connectors  on 
ports  with  Bell  303  signal  drivers  and  receivers  for  SATNET 
Satellite  IMP  interfaces  and  37-pin  Cannon-Cinch  connectors  on 
ports  with  MIL-188C  signal  drivers  and  receivers  for  MATNET 
Satellite  IMP  interfaces.  Currently,  the  simulator  has  been 
tested  successfully  with  the  Honeywell  316  computer  which  serves 
as  a  software  test-bed  for  SATNET  Satellite  IMPS. 

6.2  Satellite  IMP  Loader/Dumper  Conversion 

During  the  last  quarter,  the  Satellite  IMP  loader/dumper 
code  was  converted  to  be  compatible  with  the  64K-word  address 
space  provided  in  the  architecture  of  the  C/30  packet  switch 
processor  which  emulates  the  Honeywell  316  computer.  (In  the 
previous  quarter,  we  had  converted  the  Satellite  IMP  code 
itself.)  The  loader/dumper  code  comprises  two  separate 
stand-alone  programs,  one  which  uses  the  VDH  host  line  as  the 
access  path  and  one  which  uses  the  satellite  channel  as  the 
access  path.  The  former  is  essential  whenever  the  network  is 
down,  as  is  the  situation  when  it  is  necessary  to  reload  new 
software  that  is  incompatible  with  old  software,  while  the  latter 
is  essential  for  maintaining  isolated  Satellite  IMPS. 
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Program  conversion  required  the  removal  of  all  cases  of 
multilevel  indirect  addressing  and  all  instances  where  flags  were 
placed  in  the  sign  bits  of  words  referencing  memory.  (Before  the 
words  were  used  to  reference  memory,  though,  the  flags  in  the 
sign  bits  were  masked  off.)  Although  testing  of  the  code  was 
performed  on  a  32K-word  Honeywell  316  to  ensure  that  program 
operation  was  not  affected,  true  64K-word  operation  must  wait  for 
delivery  of  a  C/30  packet  switch  processor  with  enough  memory  and 
with  the  microcode  to  reflect  the  new  architecture. 
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